Skip to content

[Snyk] Upgrade @reduxjs/toolkit from 2.2.7 to 2.8.2 #146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[Snyk] Upgrade @reduxjs/toolkit from 2.2.7 to 2.8.2 #146

wants to merge 1 commit into from

Conversation

graymalkin77
Copy link

snyk-top-banner

Snyk has created this PR to upgrade @reduxjs/toolkit from 2.2.7 to 2.8.2.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

  • The recommended version is 11 versions ahead of your current version.

  • The recommended version was released 2 months ago.

Release notes
Package name: @reduxjs/toolkit
  • 2.8.2 - 2025-05-14

    This bugfix release fixes a bundle size regression in RTK Query from the build and packaging changes in v2.8.0.

    If you're using v2.8.0 or v2.8.1, please upgrade to v2.8.2 right away to resolve that bundle size issue!

    Changelog

    RTK Query Bundle Size

    In v2.8.0, we reworked our packaging setup to better support React Native. While there weren't many meaningful code changes, we did alter our bundling build config file. In the process, we lost the config options to externalize the @ reduxjs/toolkit core when building the RTK Query nested entry points. This resulted in a regression where the RTK core code also got bundled directly into the RTK Query artifacts, resulting in a significant size increase.

    This release fixes the build config and restores the previous RTKQ build artifact sizes.

    What's Changed

    Full Changelog: v2.8.1...v2.8.2

  • 2.8.1 - 2025-05-08

    This bugfix release makes an additional update to the package config to fix a regression that happened with Jest and jest-environment-jsdom.

    Caution

    This release had a bundle size regression. Please update to v2.8.2 to resolve that issue.

    Changes

    More Package Updates

    After releasing v2.8.0, we got reports that Jest tests were breaking. After investigation we concluded that jest-environment-jsdom was looking at the new browser package exports condition we'd added to better support JSPM, finding an ESM file containing the export keyword, and erroring because it doesn't support ES modules correctly.

    #4971 (comment) listed several viable workarounds, but this is enough of an issue we wanted to fix it directly. We've tweaked the package exports setup again, and it appears to resolve the issue with Jest.

    What's Changed

    Full Changelog: v2.8.0...v2.8.1

  • 2.8.0 - 2025-05-06

    This feature release improves React Native compatibility by updating our package exports definitions, and adds queryArg as an additional parameter to infinite query page param functions.

    Caution

    This release had a bundle size regression, as well as a breakage with jest-environment-jsdom. Please update to v2.8.2 to resolve those issues.

    Changelog

    Package Exports and React Native Compatibility

    Expo and the Metro bundler have been adding improved support for the exports field in package.json files, but those changes started printing warnings due to how some of our package definitions were configured.

    We've reworked the package definitions (again!), and this should be resolved now.

    Infinite Query Page Params

    The signature for the getNext/PreviousPageParam functions has been:

    (
    lastPage: DataType,
    allPages: Array<DataType>,
    lastPageParam: PageParam,
    allPageParams: Array<PageParam>,
  ) => PageParam | undefined | null

    This came directly from React Query's API and implementation.

    We've had some requests to make the endpoint's queryArg available in page param functions. For React Query, that isn't necessary because the callbacks are defined inline when you call the useInfiniteQuery hook, so you've already got the query arg available in scope and can use it. Since RTK Query defines these callbacks as part of the endpoint definition, the query arg isn't in scope.

    We've added queryArg as an additional 5th parameter to these functions in case it's needed.

    Other Changes

    We've made a few assorted docs updates, including replacing the search implementation to now use a local index generated on build (which should be more reliable and also has a nicer results list uI), and fixing some long-standing minor docs issues.

    What's Changed

    Full Changelog: v2.7.0...v2.8.0

  • 2.7.0 - 2025-04-16

    RTK has hit Stage 2.7! 🤣 This feature release adds support for Standard Schema validation in RTK Query endpoints, fixes several issues with infinite queries, improves perf when infinite queries provide tags, adds a dev-mode check for duplicate middleware, and improves reference stability in slice selectors and infinite query hooks.

    Changelog

    Standard Schema Validation for RTK Query

    Apps often need to validate responses from the server, both to ensure the data is correct, and to help enforce that the data matches the expected TS types. This is typically done with schema libraries such as Zod, Valibot, and Arktype. Because of the similarities in usage APIs, those libraries and others now support a common API definition called Standard Schema, allowing you to plug your chosen validation library in anywhere Standard Schema is supported.

    RTK Query now supports using Standard Schema to validate query args, responses, and errors. If schemas are provided, the validations will be run and errors thrown if the data is invalid. Additionally, providing a schema allows TS inference for that type as well, allowing you to omit generic types from the endpoint.

    Schema usage is per-endpoint, and can look like this:

    import { createApi, fetchBaseQuery } from '@ reduxjs/toolkit/query/react'
    import * as v from 'valibot'

    const postSchema = v.object({
    id: v.number(),
    name: v.string(),
    })
    type Post = v.InferOutput<typeof postSchema>

    const api = createApi({
    baseQuery: fetchBaseQuery({ baseUrl: '/' }),
    endpoints: (build) => ({
    getPost: build.query({
    // infer arg from here
    query: ({ id }: { id: number }) => /post/<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">id</span><span class="pl-kos">}</span></span>,
    // infer result from here
    responseSchema: postSchema,
    }),
    getTransformedPost: build.query({
    // infer arg from here
    query: ({ id }: { id: number }) => /post/<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">id</span><span class="pl-kos">}</span></span>,
    // infer untransformed result from here
    rawResponseSchema: postSchema,
    // infer transformed result from here
    transformResponse: (response) => ({
    ...response,
    published_at: new Date(response.published_at),
    }),
    }),
    }),
    })

    If desired, you can also configure schema error handling with the catchSchemaFailure option. You can also disable actual runtime validation with skipSchemaValidation (primarily useful for cases when payloads may be large and expensive to validate, but you still want to benefit from the TS type inference).

    See the "Schema Validation" docs section in the createApi reference and the usage guide sections on queries, infinite queries, and mutations, for more details.

    Infinite Query Fixes

    This release fixes several reported issue with infinite queries:

    • The lifecycleApi.updateCachedData method is now correctly available
    • The skip option now correctly works for infinite query hooks
    • Infinite query fulfilled actions now include the meta field from the base query (such as {request, response}). For cases where multiple pages are being refetched, this will be the meta from the last page fetched.
    • useInfiniteQuerySubscription now returns stable references for refetch and the fetchNext/PreviousPage methods

    upsertQueryEntries, Tags Performance and API State Structure

    We recently published a fix to actually process per-endpoint providedTags when using upsertQueryEntries. However, this exposed a performance issue - the internal tag handling logic was doing repeated O(n) iterations over all endpoint+tag entries in order to clear out existing references to that cache key. In cases where hundreds or thousands of cache entries were being inserted, this became extremely expensive.

    We've restructured the state.api.provided data structure to handle reverse-mapping between tags and cache keys, which drastically improves performance in this case. However, it's worth noting that this is a change to that state structure. This shouldn't affect apps, because the RTKQ state is intended to be treated as a black box and not generally directly accessed by user app code. However, it's possible someone may have depended on that specific state structure when writing a custom selector, in which case this would break. An actual example of this is the Redux DevTools RTKQ panel, which iterates the tags data while displaying cache entries. That did break with this change. Prior to releasing RTK 2.7,we released Redux DevTools 3.2.10, which includes support for both the old and new state.api.provided definitions.

    TS Support Matrix Updates

    Following with the DefinitelyTyped support matrix, we've officially dropped support for TS 5.0, and currently support TS 5.1 - 5.8. (RTK likely still works with 5.0, but we no longer test against that in CI.)

    Duplicate Middleware Dev Checks

    configureStore now checks the final middleware array for duplicate middleware references. This will catch cases such as accidentally adding the same RTKQ API middleware twice (such as adding baseApi.middleware and injectedApi.middlweware - these are actually the same object and same middleware).

    Unlike the other dev-mode checks, this is part of configureStore itself, not getDefaultMiddleware().

    This can be configured via the new duplicateMiddlewareCheck option.

    Other Changes

    createEntityAdapter now correctly handles adding an item and then applying multiple updates to it.

    The generated combineSlices selectors will now return the same placeholder initial state reference for a given slice, rather than returning a new initial state reference every time.

    useQuery hooks should now correctly refetch after dispatching resetApiState.

    What's Changed

    Full Changelog: v2.6.1...v2.7.0

  • 2.6.1 - 2025-03-07

    This bugfix release fixes several assorted types issues with the initial infinite query feature release, and adds support for an optional signal argument to createAsyncThunk.

    Changelog

    Infinite Query Fixes

    We've fixed several types issues that were reported with infinite queries after the 2.6.0 release:

    • matchFulfilled and providesTags now get the correct response types
    • We've added pre-typed Type* types to represent infinite queries, similar to the existing pre-defined types for queries and mutations
    • selectCachedArgsForQuery now supports fetching args for infinite query endpoints
    • We fixed some TS type portability issues with infinite queries that caused errors when generating TS declarations
    • useInfiniteQueryState/Subscription now correctly expect just the query arg, not the combined {queryArg, pageParam} object

    Other Improvements

    createAsyncThunk now accepts an optional {signal} argument. If provided, the internal AbortSignal handling will tie into that signal.

    upsertQueryEntries now correctly generates provided tags for upserted cache entries.

    What's Changed

    Full Changelog: v2.6.0...v2.6.1

  • 2.6.0 - 2025-02-23

    This feature release adds infinite query support to RTK Query.

    Changelog

    RTK Query Infinite Query support

    Since we first released RTK Query in 2021, we've had users asking us to add support for "infinite queries" - the ability to keep fetching additional pages of data for a given endpoint. It's been by far our most requested feature. Until recently, our answer was that we felt there were too many use cases to support with a single API design approach.

    Last year, we revisited this concept and concluded that the best approach was to mimic the flexible infinite query API design from React Query. We had additional discussions with @ TkDodo , who described the rationale and implementation approach and encouraged us to use their API design, and @ riqts provided an initial implementation on top of RTKQ's existing internals.

    We're excited to announce that this release officially adds full infinite query endpoint support to RTK Query!

    Using Infinite Queries

    As with React Query, the API design is based around "page param" values that act as the query arguments for fetching a specific page for the given cache entry.

    Infinite queries are defined with a new build.infiniteQuery() endpoint type. It accepts all of the same options as normal query endpoints, but also needs an additional infiniteQueryOptions field that specifies the infinite query behaviors. With TypeScript, you must supply 3 generic arguments: build.infiniteQuery<ResultType, QueryArg, PageParam>, where ResultType is the contents of a single page, QueryArg is the type passed in as the cache key, and PageParam is the value used to request a specific page.

    The endpoint must define an initialPageParam value that will be used as the default (and can be overridden if desired). It also needs a getNextPageParam callback that will calculate the params for each page based on the existing values, and optionally a getPreviousPageParam callback if reverse fetching is needed. Finally, a maxPages option can be provided to limit the entry cache size.

    The query and queryFn methods now receive a {queryArg, pageParam} object, instead of just the queryArg.

    For the cache entries and hooks, the data field is now an object like {pages: ResultType[], pageParams: PageParam[]>. This gives you flexibility in how you use the data for rendering.

    const pokemonApi = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: 'https://example.com/pokemon' }),
  endpoints: (build) => ({
    // 3 TS generics: page contents, query arg, page param
    getInfinitePokemonWithMax: build.infiniteQuery<Pokemon[], string, number>({
      infiniteQueryOptions: {
        // Must provide a default initial page param value
        initialPageParam: 1,
        // Optionally limit the number of cached pages
        maxPages: 3,
        // Must provide a `getNextPageParam` function
        getNextPageParam: (lastPage, allPages, lastPageParam, allPageParams) =>
          lastPageParam + 1,
        // Optionally provide a `getPreviousPageParam` function
        getPreviousPageParam: (
          firstPage,
          allPages,
          firstPageParam,
          allPageParams,
        ) => {
          return firstPageParam > 0 ? firstPageParam - 1 : undefined
        },
      },
      // The `query` function receives `{queryArg, pageParam}` as its argument
      query({ queryArg, pageParam }) {
        return `/type/${queryArg}?page=${pageParam}`
      },
    }),
  }),
})

    As with all RTKQ functionality, the core logic is UI-agnostic and does not require React. However, using the RTKQ React entry point will also auto-generate useInfiniteQuery hooks for these endpoints. Infinite query hooks fetch the initial page, then provide fetchNext/PreviousPage functions to let you trigger requests for more pages.

    function PokemonList({
    pokemonType = 'fire',
    }: {
    pokemonType?: string
    ) {
    const {
    data,
    isFetching,
    isSuccess,
    fetchNextPage,
    fetchPreviousPage,
    refetch,
    } = api.useGetInfinitePokemonInfiniteQuery(pokemonType)

    const handlePreviousPage = async () => {
    const res = await fetchPreviousPage()
    }

    const handleNextPage = async () => {
    const res = await fetchNextPage()
    }

    // data is a {pages, pageParams} object.
    // You can use those to render whatever UI you need.
    // In this case, flatten per-page arrays of results for this endpoint
    // into a single array to render a list.
    const allPokemon = data?.pages.flat() ?? [];

    // render UI with pages, show loading state, fetch as needed
    }

    Docs and Examples

    The RTK Query docs have been updated with new content and explanations for infinite queries:

    We've also added a new infinite query example app in the repo that shows several usage patterns like pagination, cursors, infinite scrolling, and limit+offset queries.

    Notes

    As with all new features and functionality, more code does mean an increase in bundle size.

    We did extensive work to byte-shave and optimize the final bundle size for this feature. Final estimates indicate that this adds about 4.2Kmin to production bundles. That's comparable to React Query's infinite query support size.

    However, given RTKQ's current architecture, that bundle size increase is included even if you aren't using any infinite query endpoints in your application. Given the significant additional functionality, that seems like an acceptable tradeoff. (And as always, having this kind of functionality built into RTKQ means that your app benefits when it uses this feature without having to add a lot of additional code to your own app, which would likely be much larger.)

    Longer-term, we hope to investigate reworking some of RTKQ's internal architecture to potentially make some of the features opt-in for better bundle size optimizations, but don't have a timeline for that work.

    Thanks

    This new feature wouldn't have been possible without huge amounts of assistance from several people. We'd like to thank:

    • @ TkDodo of TanStack Query, for happily letting us reuse the API design and implementation approach that they worked hard to figure out, and offering us his advice and knowledge on why they made specific design choices
    • @ riqts , for building the first initial POC draft PR long before we were even ready to begin thinking about this ourselves
    • @ remus-selea and @ agusterodin , for trying out various stages of the draft PRs and offering significant detailed feedback and bug reports as I iterated on the implementation

    What's Changed

    and numerous specific sub-PRs that went into that integration PR as I worked through the implementation over the last few months.

    Full Changelog: v2.5.1...v2.6.0

  • 2.5.1 - 2025-01-26

    This bugfix release fixes a logic issue with the new upsertQueryEntries util that sometimes kept entries in a pending state indefinitely.

    Changelog

    upsertQueryEntries fixes

    Users reported that in some cases, use of upsertQueryEntries to insert RTKQ cache entries prevented any further refetches of that data from happening. After investigation, we found a logic mismatch for how we handle upserts vs the existing upsertQueryData util, which meant that sometimes the entry would be left in a pending state expecting a fulfilled action from a request ID that would never happen.

    This release fixes that issue and ensures the updates and refetches happen correctly.

    What's Changed

    Full Changelog: v2.5.0...v2.5.1

  • 2.5.0 - 2024-12-11

    This feature release updates the React peer dependency to work with React 19, and fixes an additional skip token issue.

    Changelog

    React 19 Compat

    React 19 was just released! We've updated our peer dep to accept React 19, and updated our runtime and type tests to check against both React 18 and 19.

    Also see React-Redux v9.2.0 for the same peer dep update.

    Other Fixes

    We previously fixed an issue with the RTKQ core where serializeQueryArgs callbacks could be called with skipToken, potentially leading to errors. We've fixed an additional location in the useQuery hooks where that could happen as well.

    What's Changed

    Full Changelog: v2.4.0...v2.5.0

  • 2.4.0 - 2024-11-28

    This feature release includes multiple tweaks and fixes to RTK Query functionality, additional exported TS types, and drops support for TS versions earlier than 5.0.

    Changelog

    RTK Query Improvements

    Lazy query hooks can now be reset.

    retry.fail now accepts meta as a second argument.

    Tag invalidation arrays now ignore nullish values.

    We did some small internal refactoring around Maps and default values that shrank bundle size slightly.

    Bugfixes

    Passing skipToken to a query hook now bails out before running any other logic, which fixes cases where serializeQueryArgs previously threw an error because there were no args to process.

    The autoBatchEnhancer now reads window.requestAnimationFrame later, which it to work properly with Jest fake timers.

    We fixed cases where the hook result isSuccess flag would briefly flicker to false when switched to a different cache entry that was uninitialized, and would briefly flicker to true when refetching a query that previously errored.

    The listener middleware previously had inconsistent logic checks for comparing against existing listener entries (effect + type, vs effect only). It now always checks both effect + type.

    Additional TS Types

    We now export Typed[Query|Mutation]OnQueryStarted helpers to let you define onQueryStarted callbacks outside of createApi if desired.

    We also now export a CreateAsyncThunkFunction type that can be used to type userland wrappers around createAsyncThunk.

    TS Support Matrix Updates

    We've historically tried to maintain TS backwards compatibility as long as possible, and made occasional updates to our TS support matrix in minor versions over time. As of RTK 2.3.0, we officially supported back through TS 4.7.

    As of this release, we're tweaking that support policy to match the policy used by DefinitelyTyped:

    Definitely Typed only tests packages on versions of TypeScript that are less than 2 years old

@snyk-bot
fix: upgrade @reduxjs/toolkit from 2.2.7 to 2.8.2
36e402b 
Snyk has created this PR to upgrade @reduxjs/toolkit from 2.2.7 to 2.8.2.

See this package in npm:
@reduxjs/toolkit

See this project in Snyk:
https://app.snyk.io/org/cognigy-gmbh/project/92bd593a-b4bf-439d-8778-29e930fdd262?utm_source=github&utm_medium=referral&page=upgrade-pr
@graymalkin77
Copy link
Author

graymalkin77 commented Jul 27, 2025 •
edited
Loading

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

✅ code/snyk check is complete. No issues have been found. (View Details)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@graymalkin77 @snyk-bot